Ontology-based emergent ordering system and method

ABSTRACT

An method and system for handling service interdependencies in an ontology-based emergent environment that prompts service partners to provide both service type information and service parameters through a partner-portal so that the registered services can be classified into ontologies which allow parameters and rules to be associated with each registered service. The ontology modification information is generated by identifying an interdependency, manifesting the interdependency, generating new rules and parameters, and adding the new rules and parameters to the relevant service categories within the ontology database. The service partners are asked about these new parameters when registering a service.

TECHNICAL FIELD

The technical field relates in general to emergent software systems.

BACKGROUND

In the area of emergent systems, where different service providers canoffer services to a customer who in turn can compose an order combiningthe different services, structuring and managing interdependenciesbetween these services presents a challenge.

Services are typically categorized into taxonomies, which serve thesingle purpose of aiding the classification of services. Accordingly,interdependencies between services are hard-coded and therefore static.

Emergent software systems are typically established by and shared bymore than one participant. Often one participant establishes theframework and then allows other participants to deploy components intothe framework. Participants owning the components deployed to theplatform are constantly capable of providing, updating, and deletingtheir components. Apart from making the system change its behaviorunexpectedly, this feature also enables the system to perform tasks, byunexpected combinations of components that were not originally possibleor intended by any of the component suppliers. Systems that function inthis manner are referred to as “emergent.”

Emergent systems that are designed to execute a process chain thatproduces certain products typically involve a partner portal, a customerportal, and a steering component. The partner portal allows parties thatcan fulfill at least one of the steps in an overall process, to publishservices to the system. The customer portal displays the aggregatedpartner offerings to potential customers so that a customer canconfigure a customized offering by choosing among the options providedby the registered partners for each step. The steering component isconnected to both portals and steers the overall process by aggregatingpartner offerings into the customer portal and delegating customerorders.

One of the problems with current emergent systems that are designed toexecute a process chain is that the decisions the customer has toundertake are presented as if they are largely independent of oneanother and that any interdependency between categories is static.

For example, in the case of a sample process chain for the production ofboxes of chocolates there are many separate process steps, including,for example, forming items out of a certain material, covering them withicing, placing decorations on top, covering them in paper, putting themin a box, etc. It may be the case that not all of the materials of ato-be-iced item can endure the temperature that a certain icing requiresto be sufficiently liquid. Thus, a customer may end up using a currentemergent system portal to order, for example, marzipan chocolatescovered with dark chocolate though the overall-process might excludethis case.

Non-emergent systems, that contain service categories and customerchoices by hard-coded means, would not have this issue because theinterdependencies between the service categories are, indeed, static.However, emergent systems are dynamic with respect to servicecategories, often influenced by numerous parties. This dynamism oftenleads to problems and conflicts with respect to the interdependency ofservice categories.

Another problem occurs with current catalogue-based ordering systemsthat allow customers to choose from a large catalogue of goods where thecustomer can select products not only via brand name, but also based onsome properties. For example, an electronic component provider cataloguemay include a property description, such as “needs 5V power supply.”Current systems may not detect if the customer-selected components areincompatible with one another.

For example, there are different types of plugs to connect systems toone another, and the components selected by the customer might rely ondifferent plugging systems. This incompatibility is not detected bycurrent systems and may not be discovered until the customer tries toassemble the components.

One or more embodiments discussed herein can address these problems byextending emergent behavior to the interdependency handling anddetecting/resolving incompatibility issues.

SUMMARY

Accordingly, an embodiment provides a system, method and/ornon-transitory computer readable medium for handling serviceinterdependencies in an ontology-based emergent environment that promptsservice partners to provide both service type information and serviceparameters through a partner-portal so that the registered services canbe classified into ontologies which allow parameters and rules to beassociated with each registered service. The ontology modificationinformation is generated by identifying an interdependency, manifestingthe interdependency, generating new rules and parameters, and adding thenew rules and parameters to the relevant service categories within theontology database. The service partners can be asked about these newparameters when registering a service.

Accordingly, an embodiment provides an ontology-based emergent computersoftware system. The computer system comprises a partner-portal, acustomer-portal, and a steering component. The partner-portal isconfigured to receive and send partner service registration information,receive customer order information, and receive ontology databaseinformation. The customer-portal is configured to receive and send thecustomer order information, receive the ontology database information,and receive aggregate service offerings. The steering-component, whichis configured and operated by the provider, is connected to thepartner-portal and the customer-portal.

The steering-component comprises an ontology database configured toreceive ontology modification information and send the ontology databaseinformation; a service registry configured to receive the partnerservice registration information and send the aggregate serviceofferings; and an order processing system configured to receive and sendthe customer order information.

The steering-component is configured to generate ontology modificationinformation by identifying an interdependency, manifesting theinterdependency, generating new rules, generating new parameters basedon the new rules; and adding the new rules and the new parameters toservice categories within the ontology database.

The partner service registration information sent by the partner-portalcomprises service category information and parameter information.

According to another embodiment, the ontology database comprises theservice categories; the rules; and the parameters.

According to yet another embodiment, the provider generates the ontologymodification information.

According to another embodiment, the provider accepts and adds thecustomer registration information to the aggregate service offerings.

An embodiment provides a computer system that comprises apartner-portal, a customer-portal, and a steering component. Thepartner-portal is configured to receive and send partner serviceregistration information, receive customer order information, andreceive ontology database information. The customer-portal is configuredto receive and send the customer order information, receive the ontologydatabase information, and receive aggregate service offerings. Thesteering-component, which is configured and operated by the provider, isconnected to the partner-portal and the customer-portal.

The steering-component comprises an ontology database configured toreceive ontology modification information and send the ontology databaseinformation; a service registry configured to receive the partnerservice registration information and send the aggregate serviceofferings; and an order processing system configured to receive and sendthe customer order information. The steering-component is configured togenerate ontology modification information by receiving interdependencyinformation from the partner-portal, manifesting the interdependency,generating new rules, generating new parameters based on the new rules;and adding the new rules and the new parameters to service categorieswithin the ontology database. The partner service registrationinformation sent by the partner-portal comprises service categoryinformation and parameter information.

An method and/or system for handling service interdependencies in anontology-based emergent environment includes receiving, by a processor,in a service registry of a steering component, from a partner-portal,partner service registration information which includes, for a serviceoffering, service category information and service parameterinformation; aggregating, by the processor, the service offerings frompartners; and sending, by the processor, the aggregate service offeringsto a customer-portal; and storing, by the processor, in an ontologydatabase, ontology modification information and ontology databaseinformation. The steering component generates the ontology modificationinformation by interacting with a user to receive, as ontologymodification information, (i) an identification of an interdependencybetween the service offerings, (ii) new rules for service offeringswhich are interdependent, and (iii) new parameters for the serviceofferings which are interdependent based on the new rules; and storesthe new rules and the new parameters in the ontology database to servicecategories within the ontology database which correspond to the servicecategory information from the partner service registration information.The aggregate service offerings which are sent to the customer-portalinclude the ontology database information and the ontology modificationinformation.

An embodiment can provide for manifesting the interdependency betweenthe service offerings as a machine-readable rule with the parameterswithin the service category.

An embodiment can provide for manifesting, by the processor, in theontology database, the interdependency between the service offerings asa new rule-pair of a human-readable rule and a machine-readable rule.

Yet another embodiment can provide for receiving, in an order processingcomponent, from a customer-portal, customer order information whichindicates ordered service offerings based on the aggregate serviceofferings; and determining, by the processor, whether the orderedservice offerings in the customer order information are an invalid orderbased on (i) interdependency between service offerings, (ii) rules forthe service offerings which are determined to be interdependent, and(iii) violations of the parameters in the rules for the serviceofferings which are determined to be interdependent.

Still another embodiment can provide for receiving, by a customer-portalprocessor which is complementary to the steering-component, theaggregate service offerings; notifying, by the customer-portalprocessor, a user of all options for service offerings and of restrictedoptions for service offerings based on the rules; interacting, by thecustomer-portal processor, with the user to obtain customer orderinformation which indicates ordered service offerings based on theaggregate service offerings; and sending, by the customer-portalprocessor, the customer order information to the steering component todetermine whether the order is invalid based on the ontology databaseinformation and ontology modification information.

Yet another embodiment provides for interacting, by a partner-portalprocessor which is complementary to the steering-component, with theuser to obtain the partner service registration information;interacting, by the partner-portal processor, with the user to obtain(i) the identification of the interdependency between the serviceofferings, (ii) the new rules for service offerings which areinterdependent, and (iii) the new parameters for the service offeringswhich are interdependent based on the new rules.

In yet another embodiment, the ontology database information comprises:the service categories; the rules; and the parameters.

Another embodiment calls for receiving, by the processor, a request fora new service; determining, by the processor, whether a service categoryfor the new service already exists; when the service category isdetermined to exist, registering the new service with the servicecategory; when the service category is determined to not already exist:registering the new service as an existing service with a deviation tothe existing service; interacting, by the processor, with aprovider-user to determine whether to add a new category correspondingto the new service; activating, by the processor, the new service withthe deviation as the new category when the determination is to add thenew category; and activating, by the processor, the new servicecategorized as the existing service when the determination is to not addthe new category.

Another embodiment provides for accepting and adding, by the processor,customer registration information to the aggregate service offerings.

Yet another embodiment provides a non-transitory computer-readablemedium which can perform a method according to one or more of theseembodiments.

One, or a combination of more than one, or all, of the aboveembodiments, can be combined and provided as a single embodiment.

Moreover, the purpose of the foregoing abstract is to enable the U.S.Patent and Trademark Office and the public generally, and especially thescientists, engineers and practitioners in the art who are not familiarwith patent or legal terms or phraseology, to determine quickly from acursory inspection the nature and essence of the technical disclosure ofthe application. The abstract is neither intended to define theinvention of the application, which is measured by the claims, nor is itintended to be limiting as to the scope of the invention in any way.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying figures, where like reference numerals refer toidentical or functionally similar elements and which together with thedetailed description below are incorporated in and form part of thespecification, serve to further illustrate various exemplary embodimentsand to explain various principles and advantages in accordance with theembodiments.

FIG. 1 is a block diagram illustrating an example of an ontology subset;

FIG. 2 is a block diagram illustrating the data flow between thepartner-portal, the steering-component, and the customer-portal;

FIG. 3 is an excerpt of a taxonomy for a chocolate-box productionprocess;

FIG. 4 is a screenshot illustrating the partner-portal accepting a newpartner named ‘DecoratePartner’;

FIG. 5 is a screenshot illustrating the services provided by the new‘DecoratePartner’;

FIG. 6 is a screenshot illustrating a name, description, category,deviation, and status for the new ‘DecoratePartner’;

FIG. 7 is a flowchart of the procedure for adding a new service until itbecomes a possible part of the overall production process;

FIG. 8 is a screenshot illustrating the customer-portal for a chocolateboxes production example;

FIG. 9 is a screenshot illustrating a partner ‘BodyPartner’ that isabout to save a service ‘MarzipanService’ using the partner portal;

FIG. 10 is a screenshot illustrating maximum temperature informationthat is being requested from partner ‘BodyPartner’;

FIG. 11 is a block diagram that depicts an exemplary excerpt of aregistry pertaining to the service ‘MarzipanService’, the category itbelongs to, the rules regarding temperatures and the relevantparameters;

FIG. 12 is a flowchart of the process for encountering and manifesting anew interdependency;

FIG. 13 is a flowchart of a second process for encountering andmanifesting a new interdependency;

FIG. 14 is a block diagram that depicts relevant portions of a computersystem; and

FIG. 15 is a block diagram that depicts the implementation of a systemusing an Ontology-DB to store the categories including their parametersand the restrictions in both their human-readable and theirmachine-readable versions.

DETAILED DESCRIPTION

In overview, the present disclosure concerns handling serviceinterdependencies in an ontology-based emergent environment, optionallyin connection with an ordering system, that prompts service partners toprovide both service type information and service parameters through apartner-portal so that the registered services can be classified intoontologies, which allow parameters and rules to be associated with eachregistered service. The ontology modification information is generatedby identifying an interdependency, manifesting the interdependency,generating new rules and parameters, and adding the new rules andparameters to the relevant service categories within the ontologydatabase. The service partners are asked about these new parameters whenregistering a service.

The instant disclosure is provided to further explain in an enablingfashion the best modes of performing one or more embodiments. Thedisclosure is further offered to enhance an understanding andappreciation for the inventive principles and advantages thereof, ratherthan to limit in any manner the invention. The invention is definedsolely by the appended claims including any amendments made during thependency of this application and all equivalents of those claims asissued.

It is further understood that the use of relational terms such as firstand second, and the like, if any, are used solely to distinguish onefrom another entity, item, or action without necessarily requiring orimplying any actual such relationship or order between such entities,items or actions. It is noted that some embodiments may include aplurality of processes or steps, which can be performed in any order,unless expressly and necessarily limited to a particular order; i.e.,processes or steps that are not so limited may be performed in anyorder.

Much of the inventive functionality and many of the inventive principleswhen implemented, are best supported with or in software or integratedcircuits (ICs), such as a digital signal processor and softwaretherefore, and/or application specific ICs. It is expected that one ofordinary skill, notwithstanding possibly significant effort and manydesign choices motivated by, for example, available time, currenttechnology, and economic considerations, when guided by the concepts andprinciples disclosed herein will be readily capable of generating suchsoftware instructions or ICs with minimal experimentation. Therefore, inthe interest of brevity and minimization of any risk of obscuringprinciples and concepts, further discussion of such software and ICs, ifany, will be limited to the essentials with respect to the principlesand concepts used by the exemplary embodiments.

DEFINITIONS

The claims may use the following terms, which are defined to have thefollowing meanings for the purpose of the claims herein. Otherdefinitions may be specified in this document.

The term “computer system” or “computer” used herein denotes a devicesometimes referred to as a computer, laptop, personal computer, personaldigital assistant, notebook computer, personal assignment pad, server,client, mainframe computer, or evolutions and equivalents thereof.

The term “emergent ordering system” is used herein to denote a softwaresystem that can be changed unexpectedly, enabling the system to performtasks by unexpected combinations of components that may not have beenpossible or intended by component suppliers.

The term “ontology” is used herein to denote structural frameworks fororganizing information. Ontologies are used in artificial intelligence,the Semantic Web, systems engineering, software engineering, biomedicalinformatics, library science, enterprise bookmarking, and informationarchitecture as a form of knowledge representation about the world orsome part of it. The creation of domain ontologies is also fundamentalto the definition and use of an enterprise architecture framework. Thecore meaning within computer science is a model for describing the worldthat consists of a set of types, properties, and relationship types.There is also generally an expectation that the features of the model inan ontology should closely resemble the real world. Additionaldiscussion with regard to ontologies and the term “ontology” is providedbelow in connection with FIG. 15.

The term “taxonomy” is used herein to denote the practice and science ofclassification of things or concepts, including the principles thatunderlie such classification.

<End of Definitions>

As further discussed herein below, various inventive principles andcombinations thereof are employed to provide a system and/or method forhandling service interdependencies in an ontology-based emergentenvironment to be applied to a process that produces certain products.Participants can be either customers or partners offering services in afield, for example in the area of chocolate making. These participantscould be classified as platform users and not as platformadministrators. Yet, their interactions may still have the power tochange the rules of the system or to adapt the system without having anyadministrator rights. The overall system can be run by a platformprovider.

Service providers can offer their services via a partner-portal. Byrequesting not only service types (taxonomy) but also service parametersand constraints (also referred to herein as rules), the partner-portalcan classify the services in ontologies, thus allowing parameters andrules to be associated with each service. A corresponding customerportal allows for the services to be composed into an order. When anorder is composed by a customer, interdependencies are checkeddynamically. Because the service ontologies include these rules andparameters, the order is checked as it is being created, blockingservice compositions that cannot be combined in practice (or at leastproviding a notification about them). This means that the serviceproviders (rather than the portal provider) can specify the serviceconstraints and thus alter the behavior of the ordering system.

Further in accordance with exemplary embodiments, there is provided anemergent system that is designed to execute a process chain thatproduces certain products, for example boxes containing chocolates.Participants in the above sense can be either customers or partnersoffering services, for example in a specific service area, in thisexample the area of chocolate making. These participants could beclassified as platform users and not as platform administrators. Yet,their interactions still have the power to change the rules of thesystem (i.e. adapt the system) without having any administrator rights.The overall system can be run by a platform provider.

The sample process chain for the production of product, such aschocolates (used as a convenient example) involves lots of separateprocess steps. For boxes of chocolates these are, for example, formingitems of a certain material, covering them with some icing, eventuallyputting some adorations on top, covering in paper, putting in a box,etc. The software-system should enable its provider to distribute theproduction process among more than one party. For this purpose, theprovider can offer a so-called partner-portal that allows parties thatcan fulfill at least one of the steps involved in the overall process,to publish services to the system if applicable.

On the other side, the system offers a so-called customer-portal thatexhibits the aggregated partner offerings to potential customers. Acustomer can then configure a customized offering by choosing among theoptions provided by the registered partners for each step.

A steering component can be connected to both the customer-portal andthe partner-portal. The steering component can be operated by a providerto steer the overall process. This can include a first draft ofnecessary process steps that also suggests a suitable sequence in whichthe steps are to be executed. The component assembles the partner'sofferings to what the customer portal will show. This means that thiscomponent by viewing the partners offerings, decides, which processsteps are currently part of the overall process and which offerings foreach step are to be presented in the customer-portal. Secondly, thesteering component can receive the customer's orderings to steer theexecution of the overall process by delegating the separate processsteps to selected partners.

Referring now to FIG. 1, a block diagram illustrating an example of anontology subset 101 will be discussed and described. FIG. 1 provides asummary of several embodiments of a system and method for the ontologybased emergent ordering system and method. This diagram illustrates thesubset of an ontology consisting of the earlier described taxonomyexample pertaining to the production of boxes of chocolates. Of course,this system and procedure is not limited to chocolates which are merelya convenient example for illustrating the principals. In this example,there are two parameters, parameter 103 for the degree needed to meltmilk chocolate and parameter 105 for the degree that can be endured bymarzipan bodies, and a rule 107 that formulates a problem. Similar tothe way that service categories are handled, the additional concepts inthis ontology may stem from different system components (partner,provider, customer).

Referring now to FIG. 2, a block diagram illustrating the data flowbetween the partner-portal, the steering-component, and thecustomer-portal will be discussed and described. The software-systemshould enable its provider to distribute the production process amongmore than one party. For this purpose, the provider offers a so-calledpartner-portal 201 that allows parties that can fulfill at least one ofthe steps involved in the overall process, to publish services to thesystem if applicable.

On the other side, the system offers a customer-portal 203 that exhibitsthe aggregated partner offerings to potential customers. A customer canthen configure a customized offering by choosing among the optionsprovided by the registered partners for each step.

The third system component, steering-component 205 is connected to bothportals. This component, run by the provider, steers the overallprocess. This can include a first draft of necessary process steps thatalso suggests a suitable sequence in which the steps are to be executed.The steering-component assembles the partner's offerings to dictate whatthe customer portal will display. By viewing the partner's offerings,the steering-component 205 decides which process steps are currentlypart of the overall process and which offerings for each step are to bepresented in the customer-portal 203. Secondly, the centralsteering-component 205 receives the customer's orderings to steer theexecution of the overall process by delegating the separate processsteps to selected partners. Both processes, the aggregation of partnerofferings into the customer portal and the delegation of customerorders, can be automatic, semi-automatic or completely manual.

For the purpose of distributing the production process, the provideroffers a partner-portal that allows parties that can fulfill at leastone of the steps involved in the overall process, to register to thesystem. Registering here means that the potential partner providesinformation to describe itself, and to name process steps that can beundertaken and under a variety of conditions. For example, a potentialpartner may disclose as follows: “We are a company that can cover itemsin icings of two sorts and this will take us one hour per 1000 items.”

Further information can be provided to potential partners concerningwhich services would be appropriate to pertain to the overall productionprocess. Additionally, to make the services categorizationmachine-readable, the provider can publish a service categorizationtaxonomy that allows partners to publish their services as beingpertinent to one or more relevant categories.

Referring now to FIG. 3, an excerpt of such a taxonomy 301 for achocolate-box production process will be discussed and described. Whenthe partner publishes a service, this service is categorized with one ofthe provided categories if applicable. If the service is one of a newsub-kind (‘Provide Decoration Almond’), the partner chooses the nexthigher category (here ‘Provide Decoration’) and adds the deviation in afree text form. If a partner thinks a service fits into the picture butno suitable category exists, the service can be described by free textonly.

Referring now to FIGS. 4, 5, and 6, screenshots show the partner-portalaccepting a new partner named ‘DecoratePartner’ and its service todecorate a chocolate with an almond. Screen shot 401 exemplifies thatthe new partner has been saved. Once the new partner has been savedscreen shot 501 displays that upon pressing the ‘Services’ button 403,all services provided by this partner, thus far, are shown. Since thepartner has just been added to the system, there are no servicesdisplayed yet. Pressing the ‘Add Service’ button 503 opens the emptyservice editor. In screen shot 601, a name and a description areprovided for this new service. A category is chosen and the deviationbetween the service and the category is specified in the ‘Deviation’field 603.

The status of the newly added service is ‘new’ meaning that the providerhas not yet accepted the service as part of its customer offering andproduction chain. In the background, the information about a new partnerand its service offerings is stored in the database. It is up to theprovider whether the new information automatically becomes active in thesystem and thus eventually visible to other partners and/or customers.Regarding the services offerings, the process of making this activewithin the system can be dealt with in a semi-automatic manner. Similarto the one described in FIGS. 4, 5, and 6 offers something new, theprovider can decide to include the new offering (‘Provide DecorationAlmond’) into the service categorization taxonomy to encourage otherpartners to also provide this and to make such future offerings machinereadable.

In a separate step, the provider can set the new service from ‘new’ to‘active’ so that the new service offering is contained in the customeroffering as presented in the customer portal and as part of the processexecution later on. If the new service does not yet exactly meet anexisting category (i.e. a deviation was entered) it might be necessaryfor the provider to re-categorize the service to clarify at which exactplace in the production process the service is supposed to fit in,especially if no category was chosen.

Referring now to FIG. 7, a flow chart illustrating the procedure 701 ofadding a new service until it becomes a possible part of the overallproduction process will be discussed and described. In step 703, thepartner decides to register a new service. If it is determined in step705 that the service category exists, then the partner can register theservice with an exact category in step 707. In step 709, the providercan decide to use the new service that has been registered by thepartner. In step 711, the service becomes active. If, however, it isdetermined in step 705 that the service category does not exist, thenthe partner registers the service with ‘deviation’ in step 713. In step715, the provider considers whether to amend the categorization ofservices. If the provider decides not to re-categorize, then the processproceeds to step 709 so that the provider can decide to use the newservice process sans re-categorization and then activate the service instep 711. However, if the provider decides to amend the servicecategories in step 715, then the provider can add the category in step717, re-categorize in step 719, and then proceed to use the new servicein step 709 and activate the service in step 711.

Referring now to FIG. 8, a screenshot 801 shows the customer-portal forthe chocolate boxes example. The customer-portal exhibits theaggregated, accepted partner offerings to potential customers. For eachstep that is part of the overall production process, the customer isoffered a unique list of choices that the partners offer, but have notyet been set to active by the provider. A customer can then configure acustomized offering by choosing among the options provided by theregistered partners for each step. The customer-portal offers alloptions currently available as a sequence of screens, each screenallowing the selection between one or more options to a certaincriterion (body, icing, topping, etc.). Both the sequence of criteria tochoose among and the selectable options dynamically depend on thepartners' offerings and the steering component's settings. FIG. 8exemplifies a screenshot of the customer-portal for chocolate boxes andthe process step that is being considered for selection is the toppingfor the chocolates. Using the ‘Other Request’ button 803, the customercan also specify wishes for a certain category that is not yet containedin the partner's aggregated offerings. The provider deals with thesepreferences by trying to find a partner that offers such a serviceeither by accepting a service that already offers this or by publishinga suitable request on the partner portal to encourage partners to offersuch a service. The provider could encourage the partners in this way byeither adding a suitable category to the service categorization taxonomyor actively informing the partners by sending e-mails or publishing suchrequests on a suitable information board either being part of orexisting separately from the partner-portal. It is also possible toaddress a specific partner that is known to offer the relevant servicedirectly.

As soon as all steps that are currently considered to be part of theoverall process are presented to and decided by the customer, thecustomer is able to view all of the selected aggregated choices anddecides whether to send the offering. If the customer is not satisfiedwith the selected aggregated choices it is possible to go back to anystep in the decision process and re-enter the ‘send the offeringnow’-screen later.

There are multiple ways interdependencies between choices for differentcriteria can become obvious. One option is that the partner alreadystates a restriction when publishing its service, e.g. a partner knowsthat using its service to form a chocolate body out of marzipan resultsin something that does not abide icing beyond 60 degrees Celsius.Another more unpleasant way of discovering interdependencies is when acustomer orders a bad combination and the processing of this requestproves impossible. Either way the interdependency must be noted so thatfuture ordering actions are manageable.

The present ontology-based emergent ordering system represents theinterdependencies similar to the service categories described above.Since interdependencies can be more complex than just service categorytaxonomies, the term “ontology” is used to describe the present system.The service categories are a necessary part of this ontology. Apart fromthese, the ontology describes rules that must be adhered to for certainproduction steps and additional parameters that are of interest forservices of certain categories.

Similar to the way the service categories are handled, the additionalconcepts in this ontology may stem from the different sides (partner,provider and customer). As with the service categories, each side maynote such issues, but the provider is in charge of the ontology. Issuesnoticed or brought up can be added to the ontology from the provider'sside. It is up to the provider to make these restrictionsmachine-readable, so that the restrictions provided in a human-readableway as shown in the ontology subset of FIG. 1 can be communicated in amachine-readable statement with the relevant parameters identified. Thiscan be accomplished by storing a list of relevant parameters (such asparameters 103 and 105) within a service category.

With regard to the partner-portal, the provider can influence theappearance of the partner portal according to previously experiencedproblems. For example, if the temperature a body can endure is often aproblem when chocolates get iced, the service provider can always beasked about the temperature restriction of the provided body.

Referring now to FIGS. 9 and 10, the screenshot 901 shows a partner‘BodyPartner’ that is about to save a service ‘MarzipanService’ usingthe partner portal, while screenshot 1001 displays information that isbeing requested from partner ‘BodyPartner’. Having added the parameter‘Maximal Temperature’ to the ontology as information of interest whenentering a service of this category, a menu, for example, a popup, canask the service provider for this information. Additional settings inthe database may qualify this information as either optional ormandatory or might specify a set of values to choose among. In thelatter case, the portal would provide a suitable drop down box.

With regard to the customer portal, a customer is prevented fromordering something that is not producible by the current set ofavailable production steps. Alternatively, a warning system may beutilized. The format of the customer choices displayed via the customerportal, the lists of options for each process step, and the customerorder produced can be in XML format, therefore XQuery may be used toformulate these restrictions. For complex restrictions, such as‘body.maxtemperature>icing.processingtemperature’, XQuery may still beused.

One method of preventing orders that cannot be fulfilled is to use themachine-readable restrictions to exclude options that are impossible dueto previous decisions. For example, if the body-decision is presentedearlier and the option ‘marzipan’ was chosen, the icing-decision wouldnot offer the ‘dark chocolate’ icing option. This can be problematic fortwo reasons. First, it eventually makes the customer's choice dependenton the sequence in which the seemingly independent choices arepresented. Second, it might be irritating for the customer because therestricting factors are not openly laid out, but only appear by adifferent set of choices when clicking through the different choicesbackwards and forwards.

Accordingly, it can be preferable to offer all available options(available as decided by the steering-component) and additionally toprovide information on possible restrictions (rules). When deciding onmarzipan, for example, the customer may be informed that this preventsdark chocolate icing, but the option still occurs and the customer mightswitch to nougat-body later on. This requires having themachine-readable formulated restrictions also in their human-readablerepresentations. When the customer to-be reaches the ‘send the offeringnow’-screen the aggregated offerings can be presented together with therestrictions encountered by these choices. The option to order thespecified product is only offered if no restrictions are encountered.

The mechanism that is used with the taxonomies is also utilized for theentire ontology also containing the restrictions. The dynamic nature ofthe taxonomy of service categories and the generic architecture of thesystem's components, allows the overall system to be automaticallyadapted according to category suggestions from partners and customerseventually after being approved by the provider.

For the ontology this means that the restrictions pertaining to apartner's service offering or a combination thereupon are likewisedynamically dealt with. Partners and customers may make restrictionsthat become obvious on their respective sides of the overall processknown to the system and the provider's approval may make theseofficially known within the system. The provider's approval in mostcases includes a mapping of the means by which the partners and/orcustomers convey this information to a machine-readable form. If, forexample, a customer complains that it is impossible to make sure thatthe ordered chocolates do not contain bits of a certain allergenicsubstance, the provider may take this as a hint to establish a field‘may contain bits of hazelnuts’ with the ‘Form Body’ category. As withthe service categories, known restrictions may be used by generic systemcomponents to suggest likely restriction to the system users. In thehazelnut case, the ‘Form Body’ service providers are now asked to make astatement about whether they can guarantee the complete absence ofhazelnuts.

In the case of possible temperature clashes between chocolate bodies andicings the fact that this problem becomes known and is acknowledged bythe provider by representing it in the ontology may lead to the partnerportal asking the partners for the respective temperature restrictionswhen receiving the partner's offerings for body and icing services.

Restrictions as entered and seen by system users are probably in ahuman-readable form. Thus it is up to the provider when acknowledging arestriction, besides taking care for eventual new parameters to beentered along with the service offerings, to provide a machine-readableform to make the restriction usable when dealing with customer orders.The following is a sample statement in plain text:

-   -   If the body can only endure temperatures up to a certain degree        the icing can't require more than this temperature to melt.

A corresponding machine-readable query (e.g. in the form of an XQuery)is asked against the result of a customer's ordering procedure whichmight look as follows:

<order>    <shape>rectangular</shape>    <body>marzipan</body>   <icing>white icing</icing>    ... </order>

The registered partner services may be stored in a conventionalmeta-data registry, for example a service-oriented architecture (SOA)registry. The registry may also contain the taxonomy of servicecategories plus the parameters and rules pertaining to the services ofthe different categories.

Referring now to FIG. 11, a block diagram depicts a possible excerpt ofsuch a registry pertaining to the service ‘MarzipanService’, thecategory it belongs to, the involved rules 1101 about the temperaturesand the relevant parameters 1103 and 1105.

As noted and manifested by the provider, not only marzipan bodies may besubject to temperature restrictions, but bodies of any material. Thusthe rule 1101 about the relation of body and icing temperatures isconnected to the ‘Form Body’ entry 1107. The partner portal asks for theinput of parameters if a rule is connected to the actual category or oneof its ancestors.

Assume for example that the registry uses JAXR (Java API for XMLRegistries) as a format. Thus the information about the currentrestrictions of all services currently registered and necessary for thecurrent order can be assumed to be available in XML. Using XSLT(Extensible Stylesheet Language Transformations) or other knownXML-transforming techniques, the necessary information can be broughtinto a format that is easily usable for order checking, as for examplethe following:

<service>    <category>Form Body</name>   <name>body-providing-service1</name>    <material>marzipan</material>   <maxtemperature>55</maxtemperature>   <processingtemperature>15</processingtemperature>    ... </service><service>    <category>Form Body</name>   <name>body-providing-service2</name>    <material>marzipan</material>   <maxtemperature>45</maxtemperature>   <processingtemperature>20</processingtemperature>    ... </service><service>    <category>Cover with Icing</name>   <name>icing-service1</name>    <material>white icing</material>   <maxtemperature>90</maxtemperature>   <processingtemperature>50</processingtemperature>    ... </service><service>    <category>Cover with Icing</name>   <name>icing-service2</name>    <material>pink icing</material>   <maxtemperature>120</maxtemperature>   <processingtemperature>60</processingtemperature>    ... </service>

An XQuery expression that checks an order for being executable withrespect to the body-icing-restriction has to check whether there existsa pair of services (one for the body and the other for the icing) thatis compatible temperature-wise.

let $order := getActualOrder( ) let $pairs :=   for $bodyService incollection(‘services’)/service[category= ’Form Body’ and material =$order/body]   for $icingService incollection(‘services’)/service[category= ’Cover with Icing’ and material= $order/icing]   return   <pair>     <t1> { $bodyService/maxtemperature} </t1>     <t2> { $icingService/processingtemperature } </t2>   </pair>return some $pair in $pairs satisfied $pairs/t1 > $pairs/t2

Referring now to FIGS. 12 and 13, these two flowcharts show the processof encountering and manifesting a new interdependency. In the procedure1201 in FIG. 12, if the partner states the new interdependency (1203),then the provider considers manifesting (1205) the new interdependency.If the provider decides to manifest the new interdependency, theprovider adds a new rule-pair to the ontology in step 1207. Therule-pair is both human-readable and machine-readable. In step 1209, theprovider adds parameters needed by the new rule to the affected servicecategories. The final step 1211 enables the partner to be asked aboutthe new parameter values when entering services of the relevantcategory.

In the procedure 1301 in FIG. 13, if the provider notices theinterdependency in step 1303, then the provider considers manifesting(1305) the new interdependency. If the provider decides to manifest thenew interdependency, the provider adds a new rule-pair to the ontologyin step 1307. The rule-pair is both human-readable and machine-readable.In step 1309, the provider adds parameters needed by the new rule to theaffected service categories. The final step 1311 enables the customerportal to use the machine-readable rule manifestation to refuse invalidorders.

Referring now to FIG. 14, a block diagram illustrating relevant portionsof a computer system 1401 will be discussed and described. The computersystem 1401 may include one or more controllers 1403, a processor 1405,an input/output (i/o) interface 1409 for communication such as with anetwork 1407, a memory 1411, a display 1413 (optional), and/or a userinput device such as a keyboard 1415. Alternatively, or in addition tothe keyboard 1415, a user input device may comprise one or more ofvarious known input devices, such as a keypad, a computer mouse, atouchpad, a touch screen, a trackball, and/or a keyboard. The display1413 may present information to the user by way of a conventional liquidcrystal display (LCD) or other visual display, and/or by way of aconventional audible device (e.g., a speaker) for playing out audiblemessages. Portions of the computer system 1401 are well understood tothose of skill in this area and have been omitted to avoid obscuring thediscussion.

The processor 1405 may comprise one or more microprocessors and/or oneor more digital signal processors. The memory 1411 may be coupled to theprocessor 1405 and may comprise a read-only memory (ROM), arandom-access memory (RAM), a programmable ROM (PROM), and/or anelectrically erasable read-only memory (EEPROM). The memory 1411 mayinclude multiple memory locations for storing, among other things, anoperating system, data and variables 1431 for programs executed by theprocessor 1405; computer programs for causing the processor to operatein connection with various functions such as storing 1433 the ontologydatabase; generating 1435 the ontology database; partner portalfunctions 1437 (receiving/sending partner service registrationinformation, receiving customer order information, receiving ontologydatabase information); customer portal functions 1439 (receiving/sendingcustomer order information, receiving ontology database information,receiving aggregate service offerings); ontology database functions 1441(receiving ontology modification information, sending ontology databaseinformation); service registry functions 1443 (receiving partner serviceregistration information, sending aggregate service offerings); orderprocessing system functions 1445 (receiving/sending customer orderinformation); identifying 1447 an interdependency; manifesting 1449 theinterdependency; generating 1451 new rules; generating 1453 newparameters based on the new rules; adding 1455 the new rules and the newparameters to service categories within the ontology database. Thecomputer programs may be stored, for example, in ROM or PROM and maydirect the processor 1405 in controlling the operation of the computer1401. Each of these functions is considered in more detail herein, tothe extent that it is not detailed elsewhere in this document.

The user may invoke functions accessible through the user input devicesuch as the keyboard 1415. The user input device may comprise one ormore of various known input devices, such as a keyboard (1415,illustrated) and/or a pointing device, such as a mouse; the keyboard1415 may be supplemented or replaced with a scanner, card reader, orother data input device; and the pointing device may be a mouse, touchpad control device, track ball device, or any other type of pointingdevice.

Responsive to manual signaling from the user input device represented bythe keyboard 1415, in accordance with instructions stored in memory1411, and/or automatically upon receipt of certain information via thei/o interface 1409, the processor 1405 may direct the execution of thestored programs.

The computer 1401 can utilize a browser 1417, which may include one ormore browser component(s) 1419. The browser 1417 can provide aconvenient way using known techniques to interact, as further describedherein, with a user as a provider via a partner-portal, and/or a user asa customer via a customer-portal.

The computer 1401 can access a server 1423 on which is stored one ormore components, here represented by server component(s) 1425. Althoughthe components 1425 are illustrated as accessed over the network 1407,the components 1425 may be remotely and/or locally accessible from thecomputer 1401, over a wired and/or wireless connection; the components1425 do not need to be limited to a database or a server. Techniques areknown for accessing components located in a server 1423, and the like.

With regard to the server 1423 and browser 1417, it may be noted thatthe computer programs stored in the memory 1411 are illustrated on thecontroller 1403. In a client/server embodiment, one or more of thecomputer programs conveniently may be distributed to the server, such asthose marked “SERVER”, and one or more of the computer programsconveniently may be distributed to a client side, such as those marked“CLIENT”. In such a situation, the server 1423 may omit the clientcomputer programs, and the client may omit the server computer programs.In another embodiment, the computer programs may be included on anon-client-server architecture, and the requests between client-servermay be omitted.

The processor 1405 may be programmed 1433 for storing the ontologydatabase. Service categories, rules, and parameters are stored in serverstorage. Techniques are known for storing databases. The ontologydatabases can be stored in one or more formats.

The processor 1405 may be programmed for 1435 generating the ontologydatabase. This ontology database can be read from storage, modified, andthen returned to the server storage.

The processor 1405 may be programmed 1437 for partner portal functions(receiving/sending partner service registration information, receivingcustomer order information, receiving ontology database information).

The processor 1405 may be programmed 1439 for customer portal functions(receiving/sending customer order information, receiving ontologydatabase information, receiving aggregate service offerings).

The processor 1405 may be programmed 1441 for ontology databasefunctions (receiving ontology modification information, sending ontologydatabase information).

The processor 1405 may be programmed 1443 for service registry functions(receiving partner service registration information, sending aggregateservice offerings).

The processor 1405 may be programmed 1445 for order processing systemfunctions (receiving/sending customer order information).

The processor 1405 may be programmed 1447 for identifying aninterdependency.

The processor 1405 may be programmed 1449 for manifesting theinterdependency.

The processor 1405 may be programmed 1451 for generating new rules.

The processor 1405 may be programmed 1453 for generating new parametersbased on the new rules.

The processor 1405 may be programmed 1455 for adding the new rules andthe new parameters to service categories within the ontology database.

As will be understood in this field, besides the functions discussedabove, the memory 1411 can include other miscellaneous information in amisc. database, not shown, along with the usual temporary storage andother instructions for other programs not considered herein.

The computer 1401 can accommodate one or more disk drives or removablestorage (not illustrated). Typically, these might be one or more of thefollowing: a flash memory, a floppy disk drive, a hard disk drive, a CDROM, a digital video disk, an optical disk, and/or a removable storagedevice such as a USB memory stick, variations and evolutions thereof.The number and type of drives and removable storage may vary, typicallywith different computer configurations. Disk drives may be options, andfor space considerations, may be omitted from the computer system usedin conjunction with the processes described herein. The computer mayalso include a CD ROM reader and CD recorder, which are interconnectedby a bus along with other peripheral devices supported by the busstructure and protocol (not illustrated). The bus can serves as the maininformation highway interconnecting other components of the computer,and can be connected via an interface to the computer. A disk controller(not illustrated) can interface disk drives to the system bus. These maybe internal or external. The processor 1405, memory 1411, a disk driveand/or removable storage medium are referred to as “computer-readablestorage media” and provide non-transitory storage of computer programsand data.

It should be understood that FIG. 14 is described in connection withlogical groupings of functions or resources. One or more of theselogical groupings may be performed by different components from one ormore embodiments. Likewise, functions may be grouped differently,combined, or augmented without parting from the scope. For example, acomputer may be programmed with the partner portal 1437, but not thecustomer portal 1439; and/or may be programmed with the customer portal1439, but not the partner portal 1437; and/or may include or omit theservice registry 1443; or and/or may include the service registry 1443but one or both or the partner portal 1437 and/or the customer portal;and/or the functions for identifying an interdependency 1447, generatingnew rules 1451, generating new parameters 1453, and/or adding the newrules 1455 may be omitted from the computer system 1401 and provided onone or more different computer system(s). Similarly the presentdescription may describe various databases or collections of data andinformation. In some embodiments, the ontology database 1441 may beprovided remotely from the system 1401. One or more groupings of thedata or information may be omitted, distributed, combined, or augmented,or provided locally and/or remotely without departing from the scope.

Referring now to FIG. 15, the block diagram 1501 exemplifies theimplementation of such a system using an Ontology-DB to store thecategories including their parameters and the restrictions in both theirhuman-readable and their machine-readable versions.

As a special case, the ontology-based emergent ordering system can beconfigured to check property compatibility based on generic rules,without explicitly specifying the property name in the rule. For thisreason, properties could by self-describing, such as in the followingexample:

<service>    <category>Cover with Icing</name>   <name>icing-service2</name>    <matrial>pink icing</material>   <temperature> <min>60</min> <max>120</max><restriction>overlap</restriction></temperature>    ... </service>

A generic rule can be used to express: “if there are, in the componentsto be checked, properties of the same name that carry a ‘restriction’attribute, the restriction specified must hold.” In the example, thismay require that the range specified for temperature must overlap in allcomponents considered if a temperature property is specified for these.Note that the “restriction” need not even be present in all components,and that different components may describe different or multiplerestrictions. In this case, the rule could require that all of themhold. As a result, the incompatibility checks performed by the systemchange dynamically whenever such a self-describing property is added ofmodified.

Further with regard to the term “ontology”, the term “ontology” as usedherein refers to the common use of the term in computer science, whichis e.g. reflected in the following definition based on Wikipedia:

In computer science and information science, an ontology formallyrepresents knowledge as a set of concepts within a domain, using ashared vocabulary to denote the types, properties and interrelationshipsof those concepts.

Ontologies are the structural frameworks for organizing information andare used in artificial intelligence, the Semantic Web, systemsengineering, software engineering, biomedical informatics, libraryscience, enterprise bookmarking, and information architecture as a formof knowledge representation about the world or some part of it. Thecreation of domain ontologies is also fundamental to the definition anduse of an enterprise architecture framework.

The core meaning within computer science is a model for describing theworld that consists of a set of types, properties, and relationshiptypes. There is also generally an expectation that the features of themodel in an ontology should closely resemble the real world.

Common components of ontologies may include one or more of:

Individuals: instances or objects (the basic or “ground level” objects).

-   -   Classes: sets, collections, concepts, classes in programming,        types of objects, or kinds of things.    -   Attributes: aspects, properties, features, characteristics, or        parameters that objects (and classes) can have.    -   Relations: ways in which classes and individuals can be related        to one another.    -   Function terms: complex structures formed from certain relations        that can be used in place of an individual term in a statement.    -   Restrictions: formally stated descriptions of what must be true        in order for some assertion to be accepted as input.    -   Rules: statements in the form of an if-then        (antecedent-consequent) sentence that describe the logical        inferences that can be drawn from an assertion in a particular        form.    -   Axioms: assertions (including rules) in a logical form that        together comprise the overall theory that the ontology describes        in its domain of application. This definition differs from that        of “axioms” in generative grammar and formal logic. In those        disciplines, axioms include only statements asserted as a priori        knowledge. As used here, “axioms” also include the theory        derived from axiomatic statements.    -   Events: the changing of attributes or relations.

Ontologies may be encoded using ontology languages.

From the definition above it is obvious that an ontology might (but neednot) comprise rules, however, an ontology is much more than just a rulesystem because it necessarily comprises types, properties andinterrelationships of those concepts, thus modeling semantics of aselected subset of the real or a virtual world.

The detailed descriptions, which appear herein, may be presented interms of program procedures executed on a computer or a network ofcomputers. These procedural descriptions and representations herein arethe means used by those skilled in the art to most effectively conveythe substance of their work to others skilled in the art.

Further, an embodiment has been discussed in certain examples as if itis made available by a provider to a single customer with a single site.An embodiment may be used by numerous users, if preferred, and the userscan be at one or more sites.

The system used in connection herewith may rely on the integration ofvarious components including, as appropriate and/or if desired, hardwareand software servers, applications software, database engines, serverarea networks, firewall and SSL security, production back-up systems,and/or applications interface software.

A procedure is generally conceived to be a self-consistent sequence ofsteps leading to a desired result. These steps are those requiringphysical manipulations of physical quantities. Usually, though notnecessarily, these quantities take the form of electrical or magneticsignals capable of being stored on non-transitory computer-readablemedia, transferred, combined, compared and otherwise manipulated. Itproves convenient at times, principally for reasons of common usage, torefer to these signals as bits, values, elements, symbols, characters,terms, numbers, or the like. It should be noted, however, that all ofthese and similar terms are to be associated with the appropriatephysical quantities and are merely convenient labels applied to thesequantities.

Further, the manipulations performed are often referred to in terms suchas adding or comparing, which are commonly associated with mentaloperations performed by a human operator. While the discussion hereinmay contemplate the use of an operator, a human operator is notnecessary, or desirable in most cases, to perform the actual functionsdescribed herein; the operations are machine operations.

Various computers or computer systems may be programmed with programswritten in accordance with the teachings herein, or it may prove moreconvenient to construct a more specialized apparatus to perform therequired method steps. The required structure for a variety of thesemachines will be apparent from the description given herein.

Terms as used herein are intended to be interpreted as understood to oneof skill in the arts of computer science and ontologies as understood byone of skill in computer science, instead of as interpreted by anon-computer science dictionary or a more general dictionary.

Furthermore, the networks of interest for communicating betweencomputers onto which some embodiments may be distributed include thosethat transmit information in packets, for example, those known as packetswitching networks that transmit data in the form of packets, wheremessages can be divided into packets before transmission, the packetsare transmitted, and the packets are routed over network infrastructuredevices to a destination where the packets are recompiled into themessage. Such networks include, by way of example, the Internet,intranets, local area networks (LAN), wireless LANs (WLAN), wide areanetworks (WAN), and others. Protocols supporting communication networksthat utilize packets include one or more of various networkingprotocols, such as TCP/IP (Transmission Control Protocol/InternetProtocol), Ethernet, X.25, Frame Relay, ATM (Asynchronous TransferMode), IEEE 802.11, UDP/UP (Universal Datagram Protocol/UniversalProtocol), IPX/SPX (Inter-Packet Exchange/Sequential Packet Exchange),Net BIOS (Network Basic Input Output System), GPRS (general packet radioservice), I-mode and other wireless application protocols, and/or otherprotocol structures, and variants and evolutions thereof. Such networkscan provide wireless communications capability and/or utilize wirelineconnections such as cable and/or a connector, or similar.

This disclosure is intended to explain how to fashion and use variousembodiments in accordance with the invention rather than to limit thetrue, intended, and fair scope and spirit thereof. The invention isdefined solely by the appended claims, as they may be amended during thependency of this application for patent, and all equivalents thereof.The foregoing description is not intended to be exhaustive or to limitthe invention to the precise form disclosed. Modifications or variationsare possible in light of the above teachings. The embodiment(s) waschosen and described to provide the best illustration of the principlesof the invention and its practical application, and to enable one ofordinary skill in the art to utilize the invention in variousembodiments and with various modifications as are suited to theparticular use contemplated. All such modifications and variations arewithin the scope of the invention as determined by the appended claims,as may be amended during the pendency of this application for patent,and all equivalents thereof, when interpreted in accordance with thebreadth to which they are fairly, legally, and equitably entitled.

What is claimed is:
 1. A method for handling service interdependenciesin an ontology-based emergent environment comprising: receiving, by aprocessor, in a service registry of a steering component, from apartner-portal, partner service registration information which includes,for a service offering, service category information and serviceparameter information; aggregating, by the processor, the serviceofferings from partners; and sending, by the processor, the aggregateservice offerings to a customer-portal; and storing, by the processor,in an ontology database, ontology modification information and ontologydatabase information, further comprising, in the steering component,generating the ontology modification information by interacting with auser to receive, as ontology modification information, (i) anidentification of an interdependency between the service offerings, (ii)new rules for service offerings which are interdependent, and (iii) newparameters for the service offerings which are interdependent based onthe new rules; storing the new rules and the new parameters in theontology database to service categories within the ontology databasewhich correspond to the service category information from the partnerservice registration information; wherein the aggregate serviceofferings which are sent to the customer-portal include the ontologydatabase information and the ontology modification information.
 2. Themethod of claim 1, further comprising manifesting, by the processor, inthe ontology database, the interdependency between the service offeringsas a machine-readable rule with the parameters within the servicecategory.
 3. The method of claim 1, further comprising manifesting, bythe processor, in the ontology database, the interdependency between theservice offerings as a new rule-pair of a human-readable rule and amachine-readable rule.
 4. The method of claim 1, further comprisingreceiving, by the processor, in an order processing component, from acustomer-portal, customer order information which indicates orderedservice offerings based on the aggregate service offerings; anddetermining, by the processor, whether the ordered service offerings inthe customer order information are an invalid order based on (i)interdependency between service offerings, (ii) rules for the serviceofferings which are determined to be interdependent, and (iii)violations of the parameters in the rules for the service offeringswhich are determined to be interdependent.
 5. The method of claim 1,further comprising receiving, by a customer-portal processor which iscomplementary to the steering-component, the aggregate serviceofferings; notifying, by the customer-portal processor, a user of alloptions for service offerings and of restricted options for serviceofferings based on the rules; interacting, by the customer-portalprocessor, with the user to obtain customer order information whichindicates ordered service offerings based on the aggregate serviceofferings; and sending, by the customer-portal processor, the customerorder information to the steering component to determine whether theorder is invalid based on the ontology database information and ontologymodification information.
 6. The method of claim 1, further comprisinginteracting, by a partner-portal processor which is complementary to thesteering-component, with the user to obtain the partner serviceregistration information; interacting, by the partner-portal processor,with the user to obtain (i) the identification of the interdependencybetween the service offerings, (ii) the new rules for service offeringswhich are interdependent, and (iii) the new parameters for the serviceofferings which are interdependent based on the new rules.
 7. The methodof claim 1, wherein the ontology database information comprises: theservice categories; the rules; and the parameters.
 8. The method ofclaim 1, further comprising receiving, by the processor, a request for anew service; determining, by the processor, whether a service categoryfor the new service already exists; when the service category isdetermined to exist, registering the new service with the servicecategory; when the service category is determined to not already exist:registering the new service as an existing service with a deviation tothe existing service; interacting, by the processor, with aprovider-user to determine whether to add a new category correspondingto the new service; activating, by the processor, the new service withthe deviation as the new category when the determination is to add thenew category; and activating, by the processor, the new servicecategorized as the existing service when the determination is to not addthe new category.
 9. The method of claim 1, further comprising acceptingand adding, by the processor, customer registration information to theaggregate service offerings.
 10. A non-transitory computer readablemedium comprising executable instructions for performing the method ofclaim
 1. 11. An system for handling service interdependencies in anontology-based emergent environment, comprising: a processor configuredwith a steering-component, the steering component is configured toreceive, in a service registry, from a partner-portal, partner serviceregistration information which includes, for a service offering, servicecategory information and service parameter information; aggregate theservice offerings from partners; and send the aggregate serviceofferings to a customer-portal; and store, in an ontology database,ontology modification information and ontology database information,wherein the steering-component is configured to generate the ontologymodification information by interacting with a user to receive, asontology modification information, (i) an identification of aninterdependency between the service offerings, (ii) new rules forservice offerings which are interdependent, and (iii) new parameters forthe service offerings which are interdependent based on the new rules;store the new rules and the new parameters in the ontology database toservice categories within the ontology database which correspond to theservice category information from the partner service registrationinformation; wherein the aggregate service offerings which are sent tothe customer-portal include the ontology database information and theontology modification information.
 12. The system of claim 11, whereinthe processor is further configured to manifest, in the ontologydatabase, the interdependency between the service offerings as amachine-readable rule with the parameters within the service category.13. The system of claim 11, wherein the processor is further configuredto manifest, in the ontology database, the interdependency between theservice offerings as a new rule-pair of a human-readable rule and amachine-readable rule.
 14. The system of claim 11, wherein the processoris further configured to receive, in an order processing component, froma customer-portal, customer order information which indicates orderedservice offerings based on the aggregate service offerings; anddetermine whether the ordered service offerings in the customer orderinformation are an invalid order based on (i) interdependency betweenservice offerings, (ii) rules for the service offerings which aredetermined to be interdependent, and (iii) violations of the parametersin the rules for the service offerings which are determined to beinterdependent.
 15. The system of claim 11, further comprising thecustomer-portal which is complementary to the steering-component, andwhich is configured to receive the aggregate service offerings; notify auser of all options for service offerings and of restricted options forservice offerings based on the rules; interact with the user to obtaincustomer order information which indicates ordered service offeringsbased on the aggregate service offerings; and send the customer orderinformation to the steering component to determine whether the order isinvalid based on the ontology database information and ontologymodification information.
 16. The system of claim 11, further comprisingthe partner-portal which is complementary to the steering-component, andwhich is configured to interact with the user to obtain the partnerservice registration information; interact with the user to obtain (i)the identification of the interdependency between the service offerings,(ii) the new rules for service offerings which are interdependent, and(iii) the new parameters for the service offerings which areinterdependent based on the new rules.
 17. The system of claim 11,wherein the ontology database information comprises: the servicecategories; the rules; and the parameters.
 18. The system of claim 11,wherein the processor is further configured to receive a request for anew service; determine whether a service category for the new servicealready exists; when the service category is determined to exist,register the new service with the service category; when the servicecategory is determined to not already exist: register the new service asan existing service with a deviation to the existing service; interactwith a provider-user to determine whether to add a new categorycorresponding to the new service; activate the new service with thedeviation as the new category when the determination is to add the newcategory; and activate the new service categorized as the existingservice when the determination is to not add the new category.
 19. Thesystem of claim 11, wherein the processor is further configured toaccept and add customer registration information to the aggregateservice offerings.